Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

OpenHIE

OpenHIE (Open Health Information Exchange) is a community-developed architecture pattern for national-scale health information exchange. It is not a product you install; it is a way of arranging the components so that a country can add systems over time without rebuilding everything.

The problem it addresses​

Point-to-point integration does not scale. Ten systems connected directly to each other require up to 45 interfaces, each with its own authentication, mapping and failure modes. Adding an eleventh system means ten more.

OpenHIE inserts a mediating layer so each system integrates once.

The architecture​

        Point-of-service systems
   (EMR, LMIS, lab, mobile, HMIS)
                  │
                  ▼
       ┌──────────────────────┐
       │ Interoperability     │   routing, authentication,
       │ Layer (IOL)          │   mediation, audit
       └──────────────────────┘
          │      │      │      │
          ▼      ▼      ▼      ▼
     Client  Facility Provider Terminology
     Registry Registry Registry  Service
                  │
                  ▼
          Shared Health Record
                  │
                  ▼
        Health Management / analytics

Interoperability Layer​

The single door into the exchange. It authenticates callers, routes messages, runs mediators that transform between formats, and records an audit trail. OpenHIM is the common open-source implementation.

Registries​

  • Client Registry — the master patient index; resolves whether two records refer to the same person.
  • Facility Registry — canonical list of health facilities and their identifiers.
  • Health Worker Registry — providers and their roles.
  • Terminology Service — the shared vocabulary; see ICD, SNOMED CT and LOINC.

Shared Health Record​

A longitudinal, normalized store of clinical data assembled from the systems that feed the exchange.

Health Management Information System​

Aggregate reporting and analysis — typically DHIS2.

Why registries come first​

Exchange only works if both ends agree who the patient is, where the encounter happened and who provided care. Countries that build the interoperability layer before the registries usually end up rebuilding it. The identifier design questions are the same ones covered in FHIR identifiers.

Standards used​

OpenHIE is standards-based rather than standards-defining. In practice:

  • HL7 FHIR for resources and APIs
  • HL7 v2 for legacy point-of-service systems
  • IHE profiles (PIX/PDQ, XDS, ATNA) for registry and audit patterns
  • ICD, SNOMED CT and LOINC for terminology

Adopting it incrementally​

  1. Start with one exchange use case that someone actually needs.
  2. Stand up the facility registry — it is the least contentious and unblocks the rest.
  3. Add the client registry, and decide the matching strategy explicitly.
  4. Introduce the interoperability layer once there are at least two consumers.
  5. Add point-of-service systems one at a time, each with its own mediator.

In this section​

References​

Last updated on